Frame Relay

Frame Relay

Frame Relay is a network access protocol similar in principle to X.25 (a protocol is a set of procedures or rules that govern the transfer of information between devices).  The main difference between Frame Relay and X.25 is data integrity (error detection) and network error flow control (error correction). 

X.25 does all of its data checking and correcting at the network level. That means the network devices correct the corrupt data or ask for the data to be retransmitted. Thus, the cost of such checking and retransmission is network delay. 

Frame Relay performs error detection only, not error correction. It thereby leaves the task of error correction to the protocols used by intelligent devices at each end of the network. These intelligent devices will provide end-to-end data integrity. As a result, since Frame Relay relies on the device at the end to perform retransmission and error recovery, there is significantly less processing required for the network and less overall delay. 

A description can be added to an interface to help keep track of PVCs (e.g. Frame Relay to Boston)

This command specifies frame relay encapsulation.

Note: IETF frame-relay encapsulation is necessary when connecting to non-Cisco routers. The router defaults to Cisco frame-relay encapsulation if IETF is not specified. To configure IETF frame-relay encapsulation, use the "encapsulation frame-relay IETF" form of this command. Encapsulation types must match on both routers.

This command assigns a Data Link Connection Identifier (DLCI) number to the corresponding frame-relay subinterface. A DLCI is assigned by the local frame relay provider for every Permanent Virtual Circuit (PVC) connected to the router. DLCI numbers are NOT exchanged between routers. DLCI numbering at one frame relay site is mutually exclusive from DLCI numbering at another site. This concept is illustrated in the examples. DLCI numbers for Atlanta (16 and 17) need not match DLCI numbers for Boston (16) and Chicago (16). By the same token, it is OK for Boston and Chicago to both use DLCI 16.

The broadcast keyword is optional and should only be included if broadcast packets (e.g. IP RIP or IPX RIP/SAP updates) need to be forwarded out of the subinterface. In static routing examples, routing updates are not required and the keyword is omitted.

Note: In IOS versions later than 11.1(5), all point-to-point subinterfaces will forward broadcast packets by default and the option cannot be disabled. In static routing examples, even though broadcast traffic is enabled, operation is not affected as other precautions are taken to prevent the forwarding of broadcast traffic out of the subinterface (e.g. routing protocols are disabled for the subinterface).

This command configures the router with which frame-relay Local Management Interface (LMI) type to expect from the frame relay provider. LMI is a frame relay control protocol sent to the router from the frame relay switch at the service provider and is not exchanged between routers. The LMI type at one location does NOT have to match the LMI type at other locations. To illustrate this point, the examples have Boston (Cisco LMI) using a different LMI type than Atlanta (ANSI Annex D LMI).

Supported LMI Types

cisco	Generic "gang of four" LMI (default)
ansi	ANSI Annex D
q933a	CCITT Q933a

Note: When the LMI type is set for "cisco", the command will not appear in the configuration since this is the default value.

This command is used in multipoint frame-relay examples and defines a static mapping between a protocol address and a frame-relay Data Link Connection Identifier (DLCI). A DLCI is assigned by the local frame relay provider for every Permanent Virtual Circuit (PVC) connected to the router. DLCI numbers are NOT exchanged between routers. DLCI numbering at one frame relay site is mutually exclusive from DLCI numbering at another site. This concept is illustrated in the examples. DLCI numbers for Atlanta (16 and 17) need not match DLCI numbers for Boston (16) and Chicago (16). By the same token, it is OK for Boston and Chicago to both use DLCI 16.

The broadcast keyword is optional and should only be included if broadcast packets (e.g. IP RIP or IPX RIP/SAP updates) need to be forwarded out of the subinterface. In static routing examples, routing updates are not required and the keyword is omitted.

In multipoint frame-relay examples, Atlanta uses DLCI 16 to reach Boston (IP address 172.16.1.2). Therefore, Atlanta defines a static frame relay map with the command "frame-relay map ip 172.16.1.2 16". Also, Boston contains static frame-relay maps to use DLCI 16 for both Atlanta and Chicago because traffic destined to Chicago must first be sent over the PVC to Atlanta. Atlanta will then redirect the packet out its PVC to Chicago.

This command creates a logical frame-relay subinterface and defines it as a point-to-point or multipoint connection. A subinterface is treated as if it where a separate interface dedicated for a PVC to a remote site. "Serial0" indicates that the subinterface belongs to the physical serial0 interface and "16" is the unique subinterface ID number. The subinterface ID number can be any unique value between zero and 4,294,967,295 and does not have to be in any particular order (i.e. it is not necessary to begin with 1 and sequentially progress with 2,3,…etc.). In fact, to reduce confusion, it is good practice to identify a subinterface with the same number as the DLCI used on that subinterface.

This command configures an interface with an IP address and subnet mask. In IP routing examples, 10.1.1.1 is the IP address of the ethernet interface in Atlanta and 255.0.0.0 is the corresponding subnet mask. For examples in which IP is bridged, all interfaces on the router are configured with the same IP address because the router is reduced to a simple node on an IP network with only one IP address.

Copyright (c) 2001 Boson Software, Inc.  All Rights Reserved